LIST OF CONTENTS
----------------
  -> What's QuakeSDA all about?
  -> Quake executables
  -> Tools
  -> Progs
  -> Sound upgrade pak
  -> General rules
  -> Console variables
  -> Mods
  -> Maps
  -> General questions

Extended section:

  -> QdQstats
  -> Bunnyhopping
  -> Scripts
  -> Marathons
  -> Demtool

NOTE: All things listed above are included in this download.


WHAT'S QuakeSDA ALL ABOUT?
--------------------------
QuakeSDA are a collection of speed demos on maps in Quake I, or 'Classic Quake', as some refer to it today. The mission is to run through a map as fast as you can - just get to the exit.

You can choose between maps from:

  -> ID's original levels
  -> Mission Pack #1 - Scourge of Armagon
  -> Mission Pack #2 - Dissolution of Eternity 
  -> and a wide variety of custom episodes and maps.

There are several types of demos:

  -> Just running through a level, not caring about kills or secrets. These demos are called "runs".
  -> Killing every monster, and finding all the secrets. These are called "100%" demos. 
  -> There's also "cooperative" (coop for short) demos and what we call "mad coops" where any number of players take on a level for the fastest time they can manage among the competition.
  -> Marathon demos, a demo that spans one or more episodes of levels.
  -> All types of demos can be run on either skill 0 (Easy) or skill 3 (Nightmare). SDA does not accept demos recorded on Normal and Hard skill.

We can be found at these places:

  -> www.speeddemosarchive.com                                    : Main SDA page
  -> www.speeddemosarchive.com/quake                              : Quake section on SDA
  -> www.speeddemosarchive.com/quake/qdq                          : Quake done Quick section on SDA
  -> www.speeddemosarchive.com/forum/index.php/board,19.0.html    : Quake forum section on SDA
  -> www.youtube.com/user/QuakeSpeedrunning                       : YouTube video channel
  -> www.facebook.com/home.php#/group.php?gid=91979943701&ref=ts  : FaceBook video channel
  -> We have our own IRC channel at quakenet.org, #qdq            : IRC channel / irc://irc.quakenet.org/qdq
  -> quake@speeddemosarhive.com                                   : Our email address


QUAKE EXECUTABLES
-----------------
You can record demos in any of the official .exe's, that is, those that were created and distributed by ID Software.

  -> This includes Quake.exe, WinQuake.exe and GLQuake.exe.
  -> You are also allowed to use JoeQuake, which is available for Windows and Linux.
  -> MacOS and OS X users can use MacGLQuake.
  -> If you're using another platform and are unsure which engine to use, email us and ask. User created exe's can give you an advantage in an infinite number of ways that we'd never know about.

Included in this pack are the following executables:

  -> joequake-gl.exe   : JoeQuake, GL version 0.15b1862 for Windows - released 08.10.2007 - We HIGHLY recommend this one for speedrunning!
  -> joequake.exe      : JoeQuake, SOFTWARE version 0.15b1862 for Windows - released 08.10.2007
  -> joequake-gl.glx   : JoeQuake, GL version for Linux - released 07.05.2005
  -> glquake.exe       : id GL version 0.98 for Windows - released 11.02.1998
  -> winquake.exe      : id SOFTWARE version 1.09 for Windows - released 03.22.1997
  -> quake.exe         : id SOFTWARE version 1.01 for DOS - released 07.12.1996
  -> GLQuake_11b3.sit  : MacQuake, GL version 1.1b3 for MAC - released 07.05.2002


TOOLS
-----
  -> compile           : Comes with Demtool. Detailed description further down this text file.
  -> convdem           : Conversion/validation tool for Quake1 demo files by Bengt Jardrup.
  -> dempacker         : Demo packer utility by Mathias Thore.
  -> demtool           : Detailed description further down this text file.
  -> dzip v2.8         : Dzip is a program for file compression which handles Quake .dem files better than any other compression program.
  -> launcher          : Program to easily run episode/custom maps and such.
  -> pakexplorer v1.1  : For opening PAK files.
  -> qdqstats v1.8     : Detailed description further down this text file.
  -> remstud2          : ReMaic Studio 2 - Recamming (or Re-filming if you will) tool courtesy of Roman Priborkin.

A texture pack with all the prettiest and most faithful (mostly) textures for Quake 1 can be downloaded from this location:
www.speeddemosarchive.com/quake/tools/joequake_eyecandy.zip


PROGS
-----
The following stats are already "installed" into their respective PAK file and folders.

  -> qdqstats18   : QdQstats for Quake, with compile tools for marathon demos
  -> soestats17   : SoAstats, QdQstats for Hipnotic maps (Mission Pack #1)
  -> doestats172  : DoEstats, QdQstats for Rogue maps (Mission Pack #2)
  -> bbstats17    : BBstats, QdQstats for Beyond Belief
  -> rdestats17   : RDEstats, QdQstats for RDE (Runner's Delight)
  -> zerstats17   : Zerstats, QdQstats for Zerstrer
  -> qdnstats     : QdNstats, QdQstats for "naked" demos
  -> cqstats      : CQstats, QdQstats for "cheated" demos
  -> careful172   : CAREFULstats, QdQstats for "careful" demos


SOUND UPGRADE PAK
-----------------
Quake Sound Resampling Project
  -> 44khz versions of all sound files as opposed to the 11khz Quake shipped with.


GENERAL RULES
-------------
  -> The QdQstats mod for the appropriate maps you are trying are mandatory. A few maps on SDA have no stats mod avaialble though, so in that case just use the progs that came with the map.
  -> One function in QdQstats makes invisible triggers visible. You may of course use this when you practice on a level, but we do not accept demos with visible triggers in them.
  -> Another function in QdQstats displays a grenade counter. You may use the grenade counter when you record demos for SDA, but we encourage you to remove it before you send the demo to us. The grenade counter is easily removed with demtool using the -g command.
  -> There's still a few levels where you can't get all the kills, maybe because there are Zombies and no way to kill them, or it's a bug in a map that isn't fixed by the appropriate stats mod. Just follow the example of the previous 100% on that level, or if there is no 100% and you can't find all the kills, then email us to ask about it.
  -> You are allowed to pause during recording of "marathon demos". You are not allowed to pull down the console in order to adjust your aim.
  -> You can not pull down the console at the start of a single-player demo. It affects the start time of a demo, which is normally 1.4 and therefore gives an unfair advantage of up to 0.2 seconds. It can also affect the location of items/monsters in a map making it completely different. (see coagula2).
  -> You are highly discouraged to use scripts that affect movement when you record demos. The use of such scripts may result in record disqualification. You are allowed to use scripts for weapon changes and client settings. If you use more advanced scripts you have to be honest about it and inform everybody that you did by writing it in the text file.
  -> For a more elaborate discussion on scripts, read further down this text file.
  -> You are allowed to use teamplay 1 for coop demos, but you do not have to. You may pause the game at any time to allow more players to connect to the server. Any number of players may die in a coop demo as long as they don't respawn.
  -> If a record already exists on the same map and in the same category as the one you are trying, it is your duty to beat that demo's time. You should improve the demo to at least the next second; there's nothing wrong with submitting a 18.9 second demo to beat a 19.1 record.
  -> If you are doing a Run, you should also beat the time for the 100% of the same difficulty. Also, if you are doing a coop demo, make sure to beat times recorded by a lower number of players - it's no good sending in a 0:20 demo by two players, when a 0:20 single player demo exists.
  -> You can make a demo that spans one or more episodes of levels, a so called marathon. You may not die and restart a level at any point in the marathon.
  -> You may not use the cheap way on any level in the marathon except where explicitly allowed. For full game runs you must telefrag Shub, even though the secret exit is not classified as a "Cheap Way". If you have any questions about this, then email us to ask about it.
  -> For 100% marathons, you must finish the objectives of the episode. For example, you have to collect runes if they are central to the episode story.
  -> You may die. You can die in a demo as long as you finish the level. You may NOT respawn.
  -> You can NOT do the "cheap way", unless specified.


CONSOLE VARIABLES
-----------------
  -> You can change cl_*, gl_*, r_*, m_*, d_*, scr_* and v_*, to anything you want. You can't change any sv_* vars with the exception of sv_aim which you can set to anything between (and including) 0.93 and 1 (most players set this to 1). Other cvars/commands that are no touch are host_framerate, edgefriction, notarget, fly, god and noclip.
  -> If you want to get rid of dead bodies lying everywhere, you may use coop 2 in single player mode as long as the player spawn point is identical to the normal spawn point. Using this is something that we generally don't like, though.
  -> JoeQuake specifics:
     -> You can use cl_deadbodyfilter and cl_gibfilter to remove the dead and dying monsters if you wish.
     -> You are also allowed to set cl_maxfps to anything between 10 and 72, to enable low framerate tricks. If you use this you have to be honest about it and inform everybody that you did by writing it in the text file.


MODS
----
These three mods can be found in the "other demos" section of QuakeSDA.

  -> Careful  : This mod is meant to encourage the brave by only giving you 1 health at the start of any given map, and not being able to pick up more health boxes.
  -> Cheated  : This is a mod which enables you to run through any given map fully loaded with ammo and not being able to die. Hence the term "Cheated".
  -> Naked    : This mod removes ALL ammo items and weapons.


MAPS
----
ALL maps on SDA are included in the "quake-large.zip" download, so you might want to grab that instead of this one if you want to have all the maps "pre-installed". Some are in their own folder (those that comes in a PAK file), while most of them are located in the id1/maps folder. All of them have been "watervised" to see better under/into water.
Below are listed the maps that are in a PAK file, meaning that they have to go under their own seperate folder.

  -> 136       : 136
  -> alk07     : alk07
  -> bbelief   : bbstart, bbelief1, bbelief2, bbelief3, bbelief4, bbelief5, bbelief6, bbelief7, bbsecret
  -> black     : start, bskill, black1, black2, black3, bfinal
  -> cda       : cda
  -> csa       : csa
  -> czg07     : czg07, czg07a, czg07b, czg07c
  -> digs01    : start, d1, d2, d3, d4, d5, d6, d7, ds
  -> hipnotic  : start, hip1m1, hip1m2, hip1m3, hip1m4, hip1m5, hip2m1, hip2m2, hip2m3, hip2m4, hip2m5, hip2m6, hip3m1, hip3m2, hip3m3, hip3m4, hipdm1, hipend
  -> htr       : htrintro, htr
  -> jzblue    : start, jzblue_1, jzblue_2, jzblue_3, jzblue_4, jzblue_5
  -> mexx8     : mexx8, mexx8b
  -> mexx9     : mexx9, mexx9a, mexx9b, mexx9c, mexx9d
  -> mexx10    : mexx10, mexx10b
  -> n3sp03    : n3sp03, n3sp03_2
  -> ogitrev   : e1m8
  -> pg        : pgstart, pg1, pg2, pg3, pg4, pgexit
  -> prodigy   : start, p_se_1, p_se_2, p_se_3, p_se_3b, p_se_4, p_se_xxx
  -> rde       : rdstart, rd1m1, rd1m2, rd1m3, rd1m4, rdend, sphere4
  -> rogue     : start, r1m1, r1m2, r1m3, r1m4, r1m5, r1m6, r1m7, r2m1, r2m2, r2m3, r2m4, r2m5, r2m6, r2m7, r2m8
  -> skarena   : skarena
  -> shadow    : shadow
  -> zer       : start, zer1m1, zer1m2, zer1m3, zer1m4, zer1m5, zer1m6, zer1m7, zerend, zerdm1, zerdm2, zerdm3, zerdm4, zerdm5


GENERAL QUESTIONS
-----------------
  There's so many demos here! Where do I start?
  -> Depends on what you want to start doing. If you just want to be entertained, follow the "Demos" link, then go to one of the tables, like runs on the original levels, and then download some demos. We have many maps listed here, the original game, the mission paks, and user made episodes and levels.

  So what techniques can I use to gain speed?
  -> Well, there's Wallhugging, Zigzagging and Bunnyhopping...and of course, any damage that is brought upon you causes an acceleration, sometimes a very significant one, like a quadded rocket that hits you in mid air...but there are easier ones too. You can be shot up a low ledge that you normally can't reach by a grunt, or use an enforcer-blast, or an ogre-grenade-jump, or a fiend-boost, or a vore-ball-jump, or a Shambler-lightning-ride, or a....

  What the hell is 'Bunny-hopping'?
  -> Bunnying is basically zigzagging but you jump after you zig or zag. The result is that you're not on the ground, which slows you down, so you go faster.

  What is this patch that prints 'QdQstats 1.8' and the end of most demos?
  -> QdQStats is a Quake progs.dat that adds a few things for speedruners. It prints a more accurate time at the end [to five decimal points], fixes known problems with levels that you can't get 100% kills, and adds a grenade counter and trigger info.

  That grenadejump is awfully difficult to time! Suggestions?
  -> You can try using the grenade counter in QdQstats, but some people frown on its usage. A higher fps helps a lot with grenade jumps [and rocket jumps].

  Hey! I tried doing a 100% of E3M3, but I can't get 100% kills!
  -> Yeah, there's a few levels were you can't get 100% kills because there's Zombies but no way to kill them. We all used to think E3M3 was one of them, but that has been showed to be wrong. Generally if you have a problem getting all the kills, follow the example set by the previous record. If there is no record, and you feel there's a map bug, then email us.

  I've found a cool new route for the E1M4 Nightmare 100%, but there's always one monster missing. The Ogre by the silver key door never appears!
  -> This is because of the way the triggers are set up. You must kill the Fiend to the left of the silver key door before you enter the rising Ogre/Knights either side of the lift area. You can get the super nail gun if you like, but if you go into the next area with the Fiend still alive then the Ogre will NEVER teleport in.

  What is this .dz file?
  -> A .dz is the format of a file made by Dzip, a compression program that works better than a normal zip program for Quake .dem files. You'll need to download dzip to extract the dz.

  I downloaded a dz and got a pak...what do I do?
  -> If you downloaded a marathon, it's probably in a pak file. To watch this you have two options:
  -> 1. Make a marathon directory under your quake directory, then put the pak in there, making sure it's called pak0.pak. Then run quake -game marathon.
  -> 2. Rename the marathon to pak2.pak (or higher if needed) and put it in your id1 directory, then run quake normally.
  -> 3. Then you'll probably have to do "playdemo start" or playdemo of the first map in the marathon (like e2m1, hip1m1 etc.)

  So, what's a marathon?
  -> A marathon is a recording across multiple levels, done in one sitting. To make a marathon you need to use v1.6 or higher of the appropriate QdQstats mod. Then use compile.bat to compile the marathon into a .pak file.

  I have a demo I think is a record, what should I do with it?
  -> Great! Make sure it's a record, you used qdqstats, name it correctly, write a text file, dzip it and send it in to us.

  How do I make sure it's a record?
  -> For a map that's been on the tables for a while, the time on the site is very likely to be accurate. For new maps, though, there's a fair chance that the we've received an improvement since the last update and your best bet is to hassle someone on IRC to find out the current state of play.

  How should I name my files?
  -> The simplest way of getting this right is looking at what the existing demos on the map you are trying do, but:
  -> The basic pattern is <level code>_<time>.<extension>, where level code is something like "e1m1" or "gdrh", time is something like "020" or "1912" (no colons or anything like that) and extension is "txt", "dem", "dz" or "pak".
  -> For coops, the underscore in the demo file name is replaced with a character to indicate the demo. The host's demo still uses an underscore, the first player to join uses an "a", the second a "b" and so on.
  -> For marathons, call the .pak file that the compilation process produces <level code>_<time>.pak.

  That didn't make any sense. Can you give me some examples?
  -> Let's say you've done the Easy Run of e1m1 in the probably impossible time of 20 seconds. So you send us a file called e1m1_020.dz which contains the files e1m1_020.dem and e1m1_020.txt.
  -> You and a friend have done the 2-Player Easy 100% of hip1m1 in 43 seconds. What you send us: h1m1_043.dz containing: h1m1_043.txt, h1m1_043.dem, h1m1a043.dem
  -> You've done the Episode 1 NH in 11:05. You send us: e1_1105.dz containing: e1_1105.txt, e1_1105.pak

  What should I write about in my text file?
  -> Well, anything you like, really, but it's traditional to include things like your name, the map, category and time of your demo, the date you recorded the demo and a few comments on the run. Like the naming thing, have a look at what everyone else does. We appreciate but do not expect accurate information (especially if you're Dutch...).

  Anything else I can do to be helpful?
  -> It helps a little if your player name in the demo is something distinctive like your QW handle or IRC nick.

  Where do I send my demo?
  -> Mail your demo to the entire SDA team at [quake@speeddemosarchive.com], not some random member of the staff who once looked at your girlfriend funny. This is particularly important because in the event of receiving multiple demos with the same time the one that hits the SDA mailbox first is the winner.

  Do I really have to get all this stuff right?
  -> Well, no, getting things like file names wrong will not result in your demo being considered invalid, especially if you're new at this SDA game, but if you keep at it you'll get on our nerves a lot :)

  Right, I'm growing tired of typing "record demoname map" in the Quake console. How can I make demo recording a bit more ergonomical?
  -> Well bind it to a key of course! Dont know how? Type in this at the console: bind <key> "record (demoname) (mapname)". Then when you have the inevitable screw up, just hit the key.

  I want to see what the optimum would be for this run I'm trying.
  -> For practicing only, you can set host_framerate to a lower value (like 0.005, this makes speedrunning a LOT easier) to try, but remember: we do NOT accept hfr demos!

  How come I can sometimes rocketjump to a high ledge and sometimes I can't?
  -> The speed of a boost you get is framerate dependant. Low fps, low jumps, that's basically all there is to it.

  My computer is not very fast, but I need to perform this high jump in my demo. What techniques can I use to boost up my fps?
  -> You can try using a smaller screensize, lower your resolution, and if even both of these methods don't provide enough frames per sec, you can try setting "r_drawflat" to "1" (software only) or "gl_picmip" to "7" (GL only). It looks horrible but it 'flows like liquid'.

  Some levels are so dark I can't see a damn thing. How do I lighten them up a bit?
  -> In Dos/winquake you can use "r_fullbright 1" or "r_ambient 100" (100, or any other value you like). To light up your level in GL, only "r_fullbright 1" is available.

  How do I start a coop server?
  -> If you're running with four or less players its easy. The player who's going to be the server just starts quake like normal then types in "coop 1" and "maxplayers <# players>" then pick your map. Instead of the usual recording binding, you'll want to add ";wait;pause" at the end so the server will pause when the map starts. Then when the other runners connect, unpause and run away. For more than four players it's basically the same, only you have to add "-listen X" to your command line from which you boot Quake, in which is the number 4<X<17 is the number of players you want to add.  NetQuake only allows 8 player max though (even though it says 16). Remember that 99% of the maps don't have more than 4 coop starts (except for RDE levels, which have 8 =), so you'll have to start-unpause to let the second series of players enter the game.

  How do I prevent my friends getting hurt from my fire?
  -> Set "teamplay" to 1.

  OK, I did coop, set teamplay to 1, but I still killed my friend when I grenadejumped off him!
  -> Well that's because you have to wear the same color pants.

  Ok I got this QdQstats patch for my LAN coop, but the monsters keep disappearing when I kill them to prevent lag, but I don't want this since I'm on a LAN.
  -> QdQstats v1.5 has the disappearing stuff to try to help lag for over the 'net coop games. If you don't want it, get QdQstats v1.8. If you have v1.8 and you *do* want it, then set coop to 2.

  What is the difference between this place and QdQ?
  -> QdQ seeks to run through the entire game in a continuous run and refilm the demos into movies. SDA is just individual levels.


QDQSTATS (extended)
-------------------
- IMPULSEs 90-95 let you work the menu that controls the functioning of this patch.

- Any control: bring up the menu
  -> IMPULSE 90: selection left
  -> IMPULSE 91: selection right
  -> IMPULSE 92: decrease selection by 10
  -> IMPULSE 93: decrease selection by 1
  -> IMPULSE 94: increase selection by 1
  -> IMPULSE 95: increase selection by 10

- For some selections, increase/decrease instead work to toggle or activate options.

- Other commands:

  -> IMPULSE  98: Turn on velocity printing
  -> IMPULSE  99: Print player's origin
  -> IMPULSE 150: Turn off body removal
  -> IMPULSE 151: Dead bodies removed after 1 minute
  -> IMPULSE 152: Bodies removed after 5 seconds
  -> IMPULSE 153: Above plus no gibs
  -> IMPULSE 154: Bodies removed instantly
  -> IMPULSE 155: Above plus invisible nails
  -> IMPULSE 156: Above plus invis. scrag/hk fire
  -> IMPULSE 205: Genocide (kill all monsters)
  -> IMPULSE 209: Toggle the ogre-grenade counter
  -> IMPULSE 210: Toggle the grenade counter
  -> IMPULSE 211: Toggle visible triggers
  -> IMPULSE 212: Toggle trigger info
  -> IMPULSE 254: Permanent quad cheat


BUNNYHOPPING (extended)
-----------------------
- Here's some sort of explanation on how to do bunnies. It was written as a reply to an email and the answer apparently helped the receiver.

- So, example setup for a player that jumps with mouse2:
  -> bind w +forward
  -> bind s +back
  -> bind a +moveleft
  -> bind d +moveright
  -> bind mouse2 +jump
  -> +mlook

- Ok. Explaining how to bunny correct isn't easy, and explaining how to bunny good is very hard. But there are some basic pointers I hope I can give.
  -> 1. The first technique to know is the accelerating jump that nobody has bothered to think up a good name for. It's the first jump which gets the bunny sequence going, and it's where you start abusing the Quake physics ;) Stand still on the ground, swing your mouse to turn 90 degrees to the right, while holding +forward and +moveright. When you've turned your 90 degrees, press +jump and immediately "release all buttons". The 90 degree turn together with strafing will increase your speed, and you'll find yourself in a jump which is faster than ID ever intended.
     -> You have to get a feeling for the timing! You can't just do the jump after a microsecond of turning and expect high speed. You have to give the engine some time to apply its flawed physics to the player. It doesn't take very long at all but it does take a fraction of a second. Just practice doing this acceleration jump.
  -> 2. The second technique is the bunny sequence. Once you get your speed, from an acceleration jump, from a slope or from a grenade boost, if you keep jumping, you'll keep moving in the direction you started off at. You have to jump as soon as you hit the ground, because prolonged exposure to ground friction will slow you down. Do the accelerating jump and then hit +jump again right before you hit the ground, again and again. You'll keep some of your initial speed but after a few jumps you'll be standing still.
  -> 3. Here comes the part which is really hard to explain. You can maintain your speed (and even increase it) if you use strafing in the air. When you have jumped, don't release +moveright (but do release +forward!!!!!). Keep it pressed, and keep moving your mouse to the right. But only for half of the duration of the jump. After the first half of the air flight, start moving your mouse to the left, let go of +moveright, and push +moveleft instead. The ground is now approaching, and you'll have to push +jump again. Do the jump, but keep moving your mouse to the left, and keep pressing +moveleft. When you reached the top height of the second jump, again start moving your mouse to the right, let go of +moveleft, and push +moveright. This sounds very complicated but after a lot of practice you don't think about it anymore, it's all in the fingers and wrists. Remember, you don't use +forward in the sequence, only in the accelerating jump. 

- Shorter tips:
  -> One thing to keep in mind is that you're supposed to always be facing in the direction you're moving. If you follow my description in step 3 you'll hopefully find this is true :-)
  -> A bonus technique which gives you that extra speed push but isn't necessary to begin with, is to hit +forward every time before you hit the ground, and release it as soon as you've left it again. This way you'll preserve speed a little better but it's difficult and several players do just fine without it. 

- You could try this on any map, 100m is fine because there are no monsters. Using slow motion (host_framerate) is fine as well, you can learn the basics in slowmo and then increase the speed gradually until you're ready for full speed.


SCRIPTS (extended)
------------------
- Scripts have been a total pain in the arse issue for us for some years now and I honestly don't think we'll ever find a totally satisfactory middle ground. But here goes...
- A short history lesson: Back in January 2002 legendary speedrunning legend Ilkka "I'm a legend" Kurkela sent us a demo that used a script to ensure that the first couple of seconds of a demo always went smoothly. He also said "but don't post this as a record because I don't want to be associated with this kind of shit. Just watch this out of interest".
- A week or so later he contacted us again saying that he'd spotted something in a demo and he thought it looked funny, could we check it out. It did indeed look very much like the runner had scripted a trick in one of his demos. We (Myself, Nolan, Stubby, Ilkka, Stefan and a couple of others who escape my memory for the moment, and of course the person that produced the demo) discussed this at great length. The demo did indeed contain a scripted trick, the runner said he was only doing it as an experiment to see what could be done, the trick wasn't that impressive anyway and there is no doubt that the person in question could have done it without a script.
- So where did that leave us? Well, we knew that this was not a widespread problem. A couple of us spent hours watching dozens of demos in slow motion trying to find scripted tricks. We found three: e1m1 barrel, e1m1 water exit and the one mentioned above. Experimentation showed that scripting long sections was pointless due to fluctuating framerates but short sections could be automated. But they look quite obvious when slowed down. So not wishing to open up the whole can of worms and the possibiliteis of
  -> 1. accusations of "cheating" and
  -> 2. putting ideas into peoples heads 

- we decided to ask those that had used them to not use them in future and then just kept quiet about the whole thing. Besides, since 99% of runners see the whole thing as just a bit of good natured fun and wouldn't want to use scripts or other "cheats" anyway we didn't see any need to stir things up.
- All was quiet until July 2003 when people suddenly started asking about scripts and what was considered to be fair use of scripts. This prompted the SDA news update of July 25th 2003 which stated...
  -> If you DO feel you need to use a script, for example for aiming during intermission kills or to face a certain way at the start of a demo, then please credit the fact that you used a script and include the script itself in your .txt file. That way everyone can clearly see what you've done. 
- ...and we left it at that (see the old news for the full news post). Things went quiet then and people went on making cool demos and not using scripts right up until a few weeks ago when Jozsef sent in his e4m2_027. He clearly stated that he'd used a script and he published the script in his .txt just as we asked. But was this a script to far???

- What is a script and are they cheating?
  -> Simply speaking a script is a set of commands joined together. This is illustrated by the following examples (all of which I have written here from memory so I apologise if they don't actually work properly. The word "cheating" is used here to donate "an unfair use of scripts that goes against the spirit of SDA"
     ->alias nailz "impulse 4;wait;impulse 5"

- Select the NG then select the SNG. Thus it will select your best nailgun. Is this cheating? I think most people would agree that it isn't.

  -> alias cooprec "stop;wait;disconnect;wait;wait;
  -> record coopdemo;connect 69.69.69.69"
  -> Stops the current demo, starts a new one and reconnects to a coop server. Is this cheating? Obviously not!

  -> bind "SPACE" "impulse 2;+attack;wait;-attack;impulse 3"
  -> Fire the shotgun once and switch to SSG. Lifted directly from my config.cfg. Is this cheating? In my opinion it's too simple to be cheating, others may disagree.

  -> alias rjump "cl_pitchspeed 9999;+lookdown;wait;
  -> impulse 7;+jump;+attack;wait;-attack;
  -> -jump;-lookdown;centerview;cl_pitchspeed 150"
  -> This will probably perform a rocket jump. Is this cheating? Hmmm. It's quite complex but limited in use unless you want to do a simple "straight up" RJ (which isn't difficult to do anyway!). A classic example of "scripting a trick". Is it cheating? Some might say so, but this kind of RJ script has been used since Quake first came out. Besides, if you want to get any kind horizontal speed boost out of the rocket you're going to have to learn to adjust the angle of the RJ and thus learn to RJ manually anyway.

  -> alias +r "+moveright;wait;+right" 
  -> alias -r "-moveright;wait;-right" 
  -> alias +l "+moveleft;wait;+left" 
  -> alias -l "-moveleft;wait;-left" 
  -> alias r  "+r;wait;wait;wait;wait;wait;-r" 
  -> alias l  "+l;wait;wait;wait;wait;wait;-l" 
  -> bind  s  "cl_yawspeed 250;r;cl_yawspeed 380;
  -> l;r;l;r;l;r;cl_yawspeed 250;l"
  -> Finally, here's the script Joe used to perform the exit trick on e4m2. It is generally accepted that this move is impossible for a human player to do and this script is more complex than any of the other examples. Is this cheating? Some people obviously think so. Joe was totally honest about how he did it so no deception was intended but is this just too much automated help? In my view this is right on the limit. Others on the team think it's gone over the limit.

- Our official stance
  -> Nolan pretty much sums it up; "Remember this is all for fun and show anyway, don't piss people off by trying to be something you're not." People have a pretty good idea of what's fair and what's not. From now on, if you are going to use a script that you think might even be a little bit contentious mail us and ask if we'll accept it. Chances are if it's in any way complex of "not in the spirit" we'll say "Sorry, no. That's too much." In any case, if you do use one then plainly stating that you used it and putting it in the .txt is still required.


MARATHONS (extended)
--------------------

- A marathon demo is a demo which spans across several levels, recorded in one take. By the naming convention used in the Other Games section here on SDA, a marathon demo could also be called "Single Segment".

- How to record a marathon
  -> Recording a marathon is in no way different from recording any other demo in Quake. Make sure you use the appropriate version of QdQstats for the episode you are running. You may still use your typical bind, for example bind e "record marathon e1m1". But, once you finish with e1m1 (or whatever your first map in the marathon is), you just continue your running on the next level, and on the next, and the next, and next etc. Do NOT type stop in the console until you've finished the last level you wanted to run in your marathon.

- The general rule says that for run marathons, you only have to finish the game properly. For 100% marathons you also have to complete the missions of the game, for example by picking up runes etc.

- What to do with the marathon you just recorded
  -> This is where your problems begin; once you are pleased with your marathon demo and want to check it out, you try playdemo marathon in the console. It starts out OK by playing the first level, but when the second level begins, things screw up bad. This is because of a bug in Quake. But NO WORRIES, your recording is (probably) in order.

- Before you can watch your marathon you have to "compile" it. The compile program comes included with the QdQstats download. It will take as input a single Quake marathon demo file, and create as output a pak file with the marathon demo split into parts.

- Marathon compilation is a little convoluted but here's how it's done:
  -> 1. Create a compilation directory somewhere.
  -> 2. Extract the contents of compile.zip (found in the QdQstats download) into it.
  -> 3. Copy demtool into the directory, unless you have demtool in your path.
  -> 4. Put a copy of your marathon demo into the directory.
  -> 5. Open up a command window and cd your way to the directory you created.
  -> 6. Give the command compile marathon.dem pak1.pak Note that you must supply a pak name, otherwise the compilation process may crash in an uninteresting way.
  -> 7. Compilation is done. The next time you want to compile a marathon you will only need to perform steps 4-6. 

- The standard content of compile.bat does not seem to be too intelligent. Here is a variant which is a little safer and also manages to remove grenade counters from the marathon, should any be present:
  -> @echo off

  -> rem !! Compile.bat
  -> rem Usage is: compile demoname.dem pakname.pak

  -> if "%1" == "" goto help
  -> if "%2" == "" goto help

  -> mkdir tmp
  -> copy %1 tmp\foo.dem
  -> copy /y demtool.exe tmp
  -> cd tmp
  -> demtool -g foo.dem
  -> ..\mldem foo.dem x mvdemos.bat demos.lst
  -> del foo.dem
  -> call mvdemos.bat

  -> cd ..
  -> .\mlpak %2 tmp demos.lst
  -> del /q tmp
  -> rmdir tmp

  -> goto end

  -> :help
  -> echo Compile.bat
  -> echo Usage is: compile demoname.dem pakname.pak

  -> :end

- How to watch a marathon
  -> To watch a marathon .pak file that you created following the instructions above, or downloaded from somewhere on this site, you have to perform a few steps.
     -> Put the pak file somewhere in your Quake directory.
        -> It can't go just anywhere though. You must put it in a directory Quake reads pak files from. This can be your ID1 directory. It can also be any directory you supply to quake with a -game command line parameter. I have a special marathon directory, and start Quake with the -game marathon flag.
        -> You also have to name the pak file something intelligent. If the directory you put the marathon in doesn't have any other pak files, you must call the marathon pak file pak0.pak. If there already is a pak0.pak, you must call the marathon pak file pak1.pak etc.
     -> Now start Quake, and supply the directory where you put the marathon pak file as a -game parameter. As I already stated, this would be -game marathon in my case.
     -> Very likely, you will now have to start playing the marathon by typing playdemo e1m1 in the console. Of course, e1m1 must be changed into whichever demo is the first one in the marathon you're watching. For example, if you are watching a marathon run through blue hell, you start the demo by typing playdemo jzblue_1. To find out which demo is the first one in a marathon you downloaded, you can check if the accompanying text file gives any clues, or you can take an educated guess.
     -> Now watch the marathon. Hopefully, all the demos in the marathon will play after another, automatically. If not, it's time you sharpen your trout and smash whoever recorded the marathon. It better not be yourself... 


DEMTOOL (extended)
------------------
Calling Demtool without any parameters will give you a short
description of its usage. Other than that, the syntax for a
normal call will follow this scheme:

  -> demtool <switches> <files> <outfile>

Demtool will run in one of two modes, depending on the switches you
give. In "print mode", invoked by switches -i, -s, -w and -x, Demtool
will analyse its input files and print data to the console (you may
want to redirect this output to a file). If any other switches are
given, Demtool will be in "change mode" - it will read one demo, make
some modifications to its contents and write this modified demo to the
same file (or a new one, see below). You may not combine switches of
both types (except that if you use -d or -: together with -w, this will
cause Demtool to remain in "print mode").

If no switches are given, -s will be assumed as default.

Files is, you guessed it, the name of the file(s) that Demtool should
process. You may use wildcards - Demtool will expand these and process
any file that matches the pattern. Demtool expects Quake .dem files as
input. Be careful - if you omit outfile then all the changes made to
input files will be written directly to these files. Backup your original
demos if necessary.

If you omit files, *.dem will be assumed. If you omit a suffix, .dem
will be appended.

If you perform a "change mode" operation but do not want to have your
input files changed, tell the program which file to write the results
to by specifying outfile. Note that you may only specify outfile if
there's no more than one input file. If no suffix is given .dem will
be appended to outfile.

If you do a "print mode" operation you can also specify outfile - in
that case, all the output that normally goes to the console will be
redirected to this file instead.

The following paragraphs describe all the available switches in detail.
Non-QdQers may find -{f,n,s,t,v,w,:} to be the most interesting, but
check out the others, too. You may combine switches, e.g. "demtool -fv"
would be equivalent to "demtool -f -v".

-a: Insert footer before disconnect
    Specify a demo after -a (e.g., -aexample.dem), and example.dem will be
    appended to the demo (it will be inserted right before the block that
    contains disconnect). If no demo is given, footer.dem will be assumed.

-b: Add bleeding to player model
    This option is useful for refilmed demos (e.g., those made with ReMaic)
    and has two effects: First, throughout the demo, blood particles will be
    spawned at the player's position, making it look as if he's bleeding.
    The number of the blood particles will depend on his current health.
    Second, every time the player takes damage, additional particles are
    spawned - red for damage to health, grey for damage to armor and purple
    for pentagram-protected damage.

-c: Remove centerprinted messages
    Does exactly this: All the centerprinted messages are removed from the
    demo, along with accompanying talk.wav sounds.

-d: Add a disconnect message at the end
    Appends one single block containing a disconnect message to the end
    of the input files. If used in conjunction with -w, the disconnect
    message will be printed to the console instead.

-e: Remove entities during finale
    Once a finale message is encountered in a demo, all following updateentity
    messages will be removed except for those of entity 1 (the player, usually).
    This is useful to save space on demos of end-of-episode levels.

-f: Set framerate
    This is a compression feature analogous to that provided by Yonatan
    Donner's demcmp. You may specify a framerate (e.g., -f10 would set
    the framerate to 10); if you omit the number (just -f), 20 fps is
    used as default. This will remove as many frames as possible without
    letting the framerate sink below the one you gave. Note that you can
    only *reduce* the framerate (and hence the size) of any given demo,
    not increase it. Using a very high value (e.g., -f1000) is not likely
    to provide real compression but can be used to remove the "pause" frames
    that occur when you pull down the console while recording.

-g: Remove grenade counter messages
    Removes the centerprinted messages produced by QdQstats' grenade counter.

-h: Insert header at start of files
    Like -a, but header.dem is assumed as default and the demo will be inserted
    at the start of all input files. At QdQ, we use this to set some console
    variables at the start of each demo to ensure correct playback - maybe you
    can come up with other creative uses.

-i: Output config file for starting statistics
    Analyses the finishing statistics of a demo and prints a list of commands
    that generate the correct starting statistics, following on from that demo,
    when used in conjunction with QdQStats. It sets some console variables;
    e.g., use "demtool -i e1m1.dem > foo.cfg", then start Quake with one of the
    stats modifications, "exec foo.cfg", start e1m2 and you'll begin with the
    correct statistics.
    Both QdQStats 1.3/1.4 and SoAStats 1.3 are supported. Demtool will not
    work with previous versions of these modifications.

-j: Stop the screen from jarring when the player fires his weapon.

-m: Remove printed messages
    Removes all messages printed at the top of the screen. The "Version x.yz"
    startup info is preserved.

-n: Add a nop block at the start
    There's a bug in some versions of Quake that prevents it from playing back
    demos recorded in certain levels (e.g., single player recordings of start,
    or hip1m3). Demtool -n circumvents this bug by simply adding a single
    block containing a single nop at the start of each demo.

-o: Fade-out, cut intermission
    When used without any argument, demtool -o will insert stufftext messages
    causing the screen to fade black during the last 0.5 seconds of recording.
    If, however, an additional parameter is given (e.g., -o5) then the demo
    will be cut off that many seconds after the appearance of the intermission
    screen, and the fade-out will occur at that time. The demo will be pro-
    longed by repeating the last frame if it is shorter than required.

-p: Add playdemo before disconnect
    Append the name of a demo to this switch (e.g., -pdemo), and Demtool will
    insert the command "playdemo demo" just before the disconnect message.
    Useful for chaining demos. If you omit the name of a demo (just -p) then
    Demtool will make up a name by increasing the last character of the bsp the
    demo was recorded on (this would yield "playdemo e1m2" on demos of e1m1).

-P: Remove setpause messages
    Removes the messages occuring when you pause a game, including the printed
    "player [un]paused the game" and the setpause message. The extra frames
    that occur while the game is standing still are left untouched but can
    be removed via -f1000 (see above).

-q: Remove QdQStats message
    Removes the messages produced by QdQStats whenever you start or end a level.

-r: Add runes to player's inventory
    On playback, this will make runes appear in the status bar. Exactly which
    runes get added depends on the name of the level the demo was recorded on;
    demos of e2m? will get the rune from the first episode, demos of e3m? will
    get those of the first two episodes, and so on.

-s: Print statistics and time
    This will analyse and print the starting and finishing statistics of the
    player (health, armor, ammo etc.), along with the intermission time, the
    exact time needed to finish the level. If the level is never completed,
    the total running time is printed instead.

-t: Centerprint time on every frame
    This will be useful for speed runners. It allows you to gauge your per-
    formance exactly, and compare it with other demos of the same level.

-T: Print block number and time
    Similar to -t, but the block number will also be printed (the numbering
    scheme being compatible with that of demcut), and the time will be for-
    matted slightly differently.

-u: Change player's uniform color
    You need to supply an additional parameter here, e.g. -u4. The meaning of
    this number is the same as for arguments of _cl_color: shirt color * 16
    + pants color (e.g., 4 = 0*16+4 = white shirt, red pants). Useful for
    refilmed demos only.

-v: Remove entities outside fov
    Another demo compression feature, based on an idea by Yonatan Donner.
    If you're familiar with the way Quake records demos you'll know that
    it stores all those entities that are in direct line of sight from the
    player's position (roughly) regardless of the direction the player is
    facing. That means that approximately one half of the updateentity
    messages in a demo are useless - the corresponding items are never
    displayed. Demtool -v identifies these messages by way of simple
    geometric calculus and removes them, resulting in a decrease of 20%
    of demo size on average.

-I: Do not remove entities in intermissions
    This switch does nothing useful when used alone, but when used in
    conjunction with -v (i.e. -vI) it prevents entities from being removed
    in intermissions. This is sometimes necessary because of a bug in Quake
    with regard to playback in intermissions (you do not always face into
    the direction that you should, usually staring at blank walls, and Quake's
    behaviour seems not to be very consistent in this aspect).

-V: Scale volume of sound effects
    Multiplies the volume of all sound effects by the factor supplied
    with this switch, i.e. -V0.7 reduces the sounds to 70 percent of
    their original volume. Note that since most sounds in a demo are
    played at full volume normally, using a factor of larger than 1
    won't help you any (except if you already used the -V switch to
    scale down the volume before, of course).

-w: Produce lmpc-style output
    LMPC, the allround demo utility by Uwe Girlich, features the useful
    possibility to turn Quake's .dem files into readable (and editable)
    text. Demtool reproduces this feature, only it's faster. You'll still
    need lmpc to compile text files back into .dems, though. Be sure to
    redirect Demtool's output into a file if you use this switch.

-x: Extract centerprinted messages
    You'll need to supply an additional parameter to this option, e.g.
    -xstring. In that case, Demtool will look at all the centerprinted
    messages in a demo, and if it finds a centerprinted "<string>", it
    will output all the following centerprinted messages until "</string>"
    occurs. If you don't know what this is for don't ask.

-[from]:[to]: Restrict output to specified range
    (also referred to as -: elsewhere in this document)
    Demtool expects "from" and "to" to be (integer or fractional) numbers
    that represent times in seconds. Either "from" or "to" may be omitted;
    start or end of the demo, respectively, will be assumed in that case.
    This will cut the demo to include just the range given by "from" and
    "to". If used in conjunction with -w, output to console will be re-
    stricted instead.

-@: FilmAt11 fails to load demos from certain levels included in the
    Hipnotic mission pack. The reason for this is the inclusion of
    seemingly useless spawnbaseline messages with modelindex 0 which
    can be removed with this option.

--damage:
    Removes all damage messages from a demo

--vcshift:
    Removes all v_cshift commands from a demo (those used for fades)

--blood:
    Removes the extraneous blood in intermissions introduced by previous
    versions of Demtool (not that anyone would ever need this again...)

--faqproxy:
    Removes all blocks before the serverinfo message, for example those
    produced by option -n and by Perkele's FAQ-Proxy. Those blocks inter-
    fere with the operation of Remaic.

--setview:
    Removes setview messages that point to an entity that already has the
    view and are thus unnecessary; Remaic produces a lot of those.

--sounds:
    Removes all sound messages. Ambient sounds remain, and some sprites
    have sounds on their own.

--bf:
    Removes all the "bf" (brief flash) stuffcmds that occur when the
    player picks up items.

--powerups:
    Removes the palette changes induced by picking up powerups like
    the ring, pentagram, biosuit or quad. (Caution: these items are
    also removed from the inventory on the status bar.)

--ambient:
    Removes all spawnstaticsound messages.

--fadein:
    Adds stufftext "v_cshift 0 0 0 x" commands at the start of a
    demo that make the screen fade softly from black to normal.